Distributed file systems offer many compelling advantages in establishing high performance computing environments. One example is the ability to easily expand, even at large scale. In one example, a distributed file system can operate under a cluster of nodes topology, whereby clients can connect to any node among the cluster of nodes to perform file system activity. Individual nodes among the cluster of nodes each can contain their own processor(s), storage drives, memory and the like. Operating together in a cluster, the nodes can respond to client requests, store data, mirror data, and accomplish all the tasks of a modern file system. A cluster of nodes, in some cases, can provide easy scalability by providing for new nodes to be added to the cluster of nodes to increase the amount of storage space within the distributed file system and/or to meet other needs of the users of the distributed file system.
As a distributed file system receives write requests from clients and/or internal processes, those write requests can be logged and stored within an in-memory journal before committing the write data onto disk storage. For a distributed file systems with consistent workflows, write patterns may be easy to classify and efficient method for flushing writes from the in-memory journal to disk may be trivial. However, in distributed file systems that don't follow traditional classifications of write data, deciding when to flush the journal and commit at least some of the changes stored within the journal to disk can vary in efficiency. For example, disk drives can be overloaded, disk seek times can delay follow up writes, and frequently overwritten blocks can be needlessly flushed just prior to being overwritten again. Therefore, there exists a need to efficiently flush journal entries from an in-memory journal to disk such that individual disk drives are not overloaded, such that writes to a particular drive are written efficiently, and such that frequently overwritten blocks are not written prematurely.